home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1818 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. From: knarf@nasim.cube.net (Frank Bartels)
  2. Subject: screen, manuals, ...
  3. Date: Thu, 4 Aug 1994 22:13:40 +0200 (MET DST)
  4. In-Reply-To: <9408041109.AA26168@phlem.ph.kcl.ac.uk> from "sjg@phlem.ph.kcl.ac.uk" at Aug 4, 94 12:09:19 pm
  5. Mime-Version: 1.0
  6.  
  7. sjg@phlem.ph.kcl.ac.uk wrote:
  8.  
  9. > > What are the advantages of screen?  Why should I use it?   I know its
  10. > > a matter of personal preference, but so far I've found myself using most
  11. > > of Unix stuff that the list has found useful.   Never thought I'd
  12. > > admit it, but Unix utils are useful :-)
  13. > 
  14. > Screen is similar to Juergens virtual consoles. I don't know which is the
  15. > faster, but the vcons1d really screams on hardware-assisted scrolling
  16. > machines :-)
  17.  
  18. I won't compare screen to the virtual consoles. Screen is intended to be
  19. used on *one* text-based terminal, but the virtual consoles give you
  20. some terminals where screen can be run on. ;)
  21.  
  22. I think it would be a great idea to combine both. Running GEM or
  23. anything else on the "real" console and launching screen on vt01. If
  24. you redefine your function-keys on vt01 via xkey to F10->^A-0, etc.,
  25. you should be able to switch between the screens very easy. So you'll
  26. get the speed of the virtual consoles and the advantages of screen
  27. (e.g. Cut'n'Paste, Scrollback, Snapshots, etc.) *and* you'll save
  28. memory, because only one virtual console is needed, which usually eats
  29. twice the screen memory instead of just the amount of the character
  30. buffer of screen.
  31.  
  32. And remember: screen can be run through a serial line, the virtual
  33. consoles can't.
  34.  
  35. [I hope I can realize my dreams above soon, but I still had no time to
  36. install MiNT-Net since I received a larger hard-disk for my TT ;)]
  37.  
  38. > My manual paging suite is now available for ftp at
  39. >                   phl[ei]m.ph.kcl.ac.uk:/pub/MiNT/mans/*
  40. > 
  41. > It copes with compressed man and cat pages, calls apropos when invoked with
  42. > the -k option and it comes with a simple-minded mkwhatis (needs to be run
  43. > from the /usr/man directory) which will generate the whatis database from
  44. > the compressed man pages.
  45.  
  46. Sounds great, I'll get it soon. Does it know what to do if MANPATH is
  47. set to /usr/local/man:/usr/man?
  48.  
  49. > Now a compressed filesystem would be a neat idea :-)))))))) So long as we had
  50. > a compressed fsck as well :-)))))))))
  51.  
  52. I won't use it, because MiNT & MinixFS is not *that* stable. Just
  53. think about all the problems the DOS user have with their stacker or
  54. what's it called. And they don't have an update-daemon, they never
  55. have to sync...
  56.  
  57. Did you have a look at gzexe?
  58.  
  59. I'd like to see an 'info'-program which copes with gzipped
  60. info-pages:
  61.  
  62. % du /usr/local/info
  63. 6380    /usr/local/info
  64.  
  65. [These are kilobytes, no dumb SysV du ;)]
  66.  
  67. Bye,
  68. Knarf
  69. -- 
  70.     Frank Bartels    |      UUCP/ZModem: + 49 89 5469593       | MiNT is
  71. knarf@nasim.cube.net | Login: nuucp Index: /pub/ls-lR.nasim.gz | Now TOS!
  72.